A couple of issues in testing this:

It fails to hide the spinner when loading a PDF rather than an HTML page. The background colour behind the spinner is also wrong when loading a PDF (it's set by PDF.js):

I think the background colour could also be an issue with HTML pages that set a non-white background.

For HTML pages also I notice that the spinner is still shown for a second on top of the page contents once they become visible:

Instead of showing a spinner in front of the third-party page or PDF, I wonder if a better approach might be to show a loading bar above it? Either at the very top of the iframe, or above the iframe. Some sites show a simple blue line, a few pixels high, at the top of the page that moves from left to right as the page loads. The advantage of this is no clashing between our spinner and the site or PDF behind it. GitHub does this for example:

The problem of course is that using a progress bar rather than a spinner requires the code to have some at least rough idea of how much of the site has loaded, not just that it's still loading. There are bar-shaped loading indicators that simply use animation to indicate that "something is happening" without indicating how much progress has been made, this sort of thing:

I have pushed to changes to address the issues above:

• The loading indicator no longer lingers in the PDF viewer. The fix is to make the PDF viewer iframe send the same document metadata message to the parent that a ViaHTML frame does. This also fixes the tab title in the PDF viewer.
• The display of the loading indicator has been delayed by .5s so that it doesn't flicker briefly if the content loads quickly
• The loading indicator now fades in and out to reduce the flicker effect

Regarding the loading indicator style, I considered a GitHub-style progress bar but I thought this might be too hidden on the initial page load. On GitHub this indicator is shown when transitioning from one GH page to another so there isn't the "blank slate" problem on first load. I think we'd have to try some different variants to be sure.

An issue that is not addressed here is what to do if the Via 3 request succeeds and renders the wrapper page containing an iframe, but the ViaHTML page fails to load for any reason or renders a page without the banner_insert.html header. From what I can find so far, there is no event that gets emitted if the iframe fails to load for any reason. If that is the case then the best we can do is to add a timeout.

Edit: Related issue about this: whatwg/html#125. Our use case is very similar to the ones in the comments that mention using postMessage to communicate with a parent frame.

Works with PDFs now 👍

There are examples of the "bar at the top of the frame" design being used in initial page loads. PDF.js does it for example (sorry long/slow GIF, wait for it):

The problem is that, in Safari, the user can be faced with a blank white window and nothing happening, right? If the only thing in the blank white window is a loading bar at the top, the user will notice it.

I really think that showing a spinner with transparent elements over arbitrary third-party content is a problem. It creates visual clashing and legibility issues that will vary depending on the third-party site that's behind it, and it just sort of looks like broken CSS. Example:

Here's what it'll look like if the third-party site uses the same colour as we do:

Maybe put another way: there's a reason why browsers show a tiny loading spinner up on the tab (where they have control of the background colour and surroundings), rather than a big one in the middle of the window

@robertknight Do you want to push ahead with this design, or try out some variants? And do you want to do anything about the case when the iframe's contents fail to load?

I have changed the loading spinner to a solid bar that is similar to GitHub's, but using our brand color instead of blue and is slightly thicker to make it more visible. This avoids an issue where the spinner can obscure the page content if it takes a long time in between some content appearing and the DOMContentLoaded event being fired in the page. New version:

As with GitHub's bar, this one doesn't use an indeterminate state during the initial load. Instead it just grows to a fixed progress percentage and stops until loading is "done" at which point it grows to 100%.

To get a sense of what it looks like under different conditions, open Chrome devtools, go to the Network tab and enable connection throttling at various levels.